SPACE 2

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / program / 318 / utilsrc / make-4 < prev next >

Wrap

Text File | 1988-10-20 | 30.8 KB | 795 lines

 File: make, Node: Automatic, Next: Pattern Match, Prev: Pattern Examples, Up: Pattern Rules Automatic Variables ------------------- Suppose you are writing a pattern rule to compile a `.c' file into a `.o' file: how do you write the `cc' command so that it operates on the right source file name? You can't write the name in the command, because the name is different each time the implicit rule is applied. What you do is use a special feature of `make', the "automatic variables". These variables have values computed afresh for each rule that is executed, based on the target and dependencies of the rule. In this example, you would use `$@' for the object file name and `$<' for the source file name. Here is a table of automatic variables: `$@' The file name of the target of the rule. If the target is an archive member, then `$@' is the name of the archive file. `$%' The target member name, when the target is an archive member. For example, if the target is `foo.a(bar.o)' then `$%' is `bar.o' and `$@' is `foo.a'. `$%' is empty when the target is not an archive member. `$<' The name of the first dependency. `$?' The names of all the dependencies that are newer than the target, with spaces between them. `$^' The names of all the dependencies, with spaces between them. `$*' The stem with which an implicit rule matches (*Note Pattern Match::.). If the target is `dir/a.foo.b' and the target pattern is `a.%.b' then the stem is `dir/foo'. The stem is useful for constructing names of related files. `$?' is useful even in explicit rules when you wish to operate on only the dependencies that have changed. For example, suppose that an archive named `lib' is supposed to contain copies of several object files. This rule copies just the changed object files into the archive: lib: foo.o bar.o lose.o win.o ar c lib $? Of the variables listed above, four have values that are single file names. These four have variants that get just the file's directory name or just the file name within the directory. The variant variables' names are formed by appending `D' or `F', respectively. These variants are semi-obsolete in GNU `make' since the functions `dir' and `notdir' can be used to get an equivalent effect (*Note Filename Functions::.). Here is a table of the variants: `$(@D)' The directory part of the file name of the target. If the value of `$@' is `dir/foo.o' then `$(@D)' is `dir/'. This value is `./' if `$@' does not contain a slash. `$(@D)' is equivalent to `$(dir $@)'. `$(@F)' The file-within-directory part of the file name of the target. If the value of `$@' is `dir/foo.o' then `$(@F)' is `foo.o'. `$(@F)' is equivalent to `$(notdir $@)'. `$($/)' The same as `$(@F)', for compatibility with some other versions of `make'. `$(%D)' `$(%F)' The directory part and the file-within-directory part of the archive member name. `$(*D)' `$(*F)' The directory part and the file-within-directory part of the stem; `dir/' in this example. `$(<D)' `$(<F)' The directory part and the file-within-directory part of the first implicit dependency.  File: make, Node: Pattern Match, Next: Match-Anything Rules, Prev: Automatic, Up: Pattern Rules How Patterns Match ------------------ A target pattern is composed of a `%' between a prefix and a suffix, either of which may be empty. The pattern matches a file name only if the file name starts with the prefix and ends with the suffix, without overlap. The text between the prefix and the suffix is called the "stem". Thus, when the pattern `%.o' matches the file name `test.o', the stem is `test'. The pattern rule dependencies are turned into actual file names by substituting the stem for the character `%'. Thus, if in the same example one of the dependencies is written as `%.c', it expands to `test.c'. When the target pattern does not contain a slash (and usually it does not), directory names in the file names are removed from the file name before it is compared with the target prefix and suffix. The directory names, along with the slash that ends them, are added back to the stem. Thus, `e%t' does match the file name `src/eat', with `src/a' as the stem. When dependencies are turned into file names, the directories from the stem are added at the front, while the rest of the stem is substituted for the `%'. The stem `src/a' with a dependency pattern `c%r' gives the file name `src/car'.  File: make, Node: Match-Anything Rules, Next: Canceling Rules, Prev: Pattern Match, Up: Pattern Rules Match-Anything Pattern Rules ---------------------------- When a pattern rule's target is just `%', it matches any filename whatever. We call these rules "match-anything" rules. They are very useful, but it can take a lot of time for `make' to think about them, because it must consider every such rule for each file name listed either as a target or as a dependency. Suppose the makefile mentions `foo.c'. For this target, `make' would have to consider making it by linking an object file `foo.c.o', or by C compilation-and-linking in one step from `foo.c.c', or by Pascal compilation-and-linking from `foo.c.p', and many other possibilities. We know these possibilities are ridiculous since `foo.c' is a C source file, not an executable. If `make' did consider these possibilities, it would ultimately reject them, because files such as `foo.c.o', `foo.c.p', etc. would not exist. But these possibilities are so numerous that `make' would run very slowly if it had to consider them. To gain speed, we have put various constraints on the way `make' considers match-anything rules. There are two different constraints that can be applied, and each time you define a match-anything rule you must choose one or the other for that rule. One choice is to mark the match-anything rule as "terminal" by defining it with a double colon. When a rule is terminal, it does not apply unless its dependencies actually exist. Dependencies that could be made with other implicit rules are not good enough. For example, the built-in implicit rules for extracting sources from RCS and SCCS files are terminal; as a result, if the file `foo.c,v' does not exist, `make' will not even consider trying to make it as an intermediate file from `foo.c,v.o' or from `RCS/SCCS/s.foo.c,v'. RCS and SCCS files are generally ultimate source files, which should not be remade from any other files; therefore, `make' can save time by not looking for ways to remake them. If you do not mark the match-anything rule as terminal, then it is nonterminal. A nonterminal match-anything rule cannot apply to a file name that indicates a specific type of data. A file name indicates a specific type of data if some non-match-anything implicit rule target matches it. For example, the file name `foo.c' matches the target for the pattern rule `%.c : %.y' (the rule to run Yacc). Regardless of whether this rule is actually applicable (which happens only if there is a file `foo.y'), the fact that its target matches is enough to prevent consideration of any nonterminal match-everything rules for the file `foo.c'. Thus, `make' will not even consider trying to make `foo.c' as an executable file from `foo.c.o', `foo.c.c', `foo.c.p', etc. The motivation for this constraint is that nonterminal match-everything rules are used for making files containing specific types of data (such as executable files) and a file name with a recognized suffix indicates a specific different type of data (such as a C source file). Special built-in dummy pattern rules are provided solely to recognize certain file names so that nonterminal match-everything rules won't be considered. These dummy rules have no dependencies and no commands, and they are ignored for all other purposes. For example, the built-in implicit rule %.p : exists to make sure that Pascal source files such as `foo.p' match a specific target pattern and thereby prevent time from being wasted looking for `foo.p.o' or `foo.p.c'.  File: make, Node: Canceling Rules, Prev: Match-Anything Rules, Up: Pattern Rules Canceling Implicit Rules ------------------------ You can override a built-in implicit rule by defining a new pattern rule with the same target and dependencies, but different commands. When the new rule is defined, the built-in one is replaced. The new rule's position in the sequence of implicit rules is determined by where you write the new rule. You can cancel a built-in implicit rule by defining a pattern rule with the same target and dependencies, but no commands. For example, the following would cancel the rule that runs the assembler: %.o : %.s  File: make, Node: Last Resort, Next: Suffix Rules, Prev: Pattern Rules, Up: Implicit Defining Last-Resort Default Rules ================================== You can define a last-resort implicit rule by writing a rule for the target `.DEFAULT'. Such a rule's commands are used for all targets and dependencies that have no commands of their own and for which no other implicit rule applies. Naturally, there is no `.DEFAULT' rule unless you write one. For example, when testing a makefile, you might not care if the source files contain real data, only that they exist. Then you might do this: .DEFAULT: touch $@ to cause all the source files needed (as dependencies) to be created silently.  File: make, Node: Suffix Rules, Next: Search Algorithm, Prev: Last Resort, Up: Implicit Old-Fashioned Suffix Rules ========================== "Suffix rules" are the old-fashioned way of defining implicit rules for `make'. Suffix rules are obsolete because pattern rules are more general and clearer. They are supported in GNU `make' for compatibility with old makefiles. They come in two kinds: "double-suffix" and "single-suffix". A double-suffix rule is defined by a pair of suffixes: the target suffix and the source suffix. It matches any file whose name ends with the target suffix. The corresponding implicit dependency is to the file name made by replacing the target suffix with the source suffix. A two-suffix rule whose target and source suffixes are `.o' and `.c' is equivalent to the pattern rule `%.o : %.c'. A single-suffix rule is defined by a single suffix, which is the source suffix. It matches any file name, and the corresponding implicit dependency name is made by appending the source suffix. A single-suffix rule whose source suffix is `.c' is equivalent to the pattern rule `% : %.c'. Suffix rule definitions are recognized by comparing each rule's target against a defined list of known suffixes. When `make' sees a rule whose target is a known suffix, this rule is considered a single-suffix rule. When `make' sees a rule whose target is two known suffixes concatenated, this rule is taken as a double-suffix rule. For example, `.c' and `.o' are both on the default list of known suffixes. Therefore, if you define a rule whose target is `.c.o', `make' takes it to be a double-suffix rule with source suffix `.c' and target suffix `.o'. For example, here is the old fashioned way to define the rule for compiling a C source: .c.o: $(CC) -c $(CFLAGS) -o $@ $< The known suffixes are simply the names of the dependencies of the special target `.SUFFIXES'. You can add your own suffixes by writing a rule for `.SUFFIXES' that adds more dependencies, as in .SUFFIXES: .hack .win which adds `.hack' and `.win' to the end of the list of suffixes. If you wish to eliminate the default known suffixes instead of just adding to them, write a rule for `.SUFFIXES' with no dependencies. By special dispensation, this eliminates all existing dependencies of `.SUFFIXES'. You can then write another rule to add the suffixes you want. For example, .SUFFIXES: # Delete the default suffixes .SUFFIXES: .c .o .h # Define our suffix list The `-r' flag causes the default list of suffixes to be empty.  File: make, Node: Search Algorithm, Prev: Last Resort, Up: Implicit Implicit Rule Search Algorithm ============================== Here is the procedure `make' uses for searching for an implicit rule for a target T. This procedure is followed for each double-colon rule with no commands, for each target of ordinary rules none of which have commands, and for each dependency that is not the target of any rule. It is also followed recursively for dependencies that come from implicit rules, in the search for a chain of rules. Suffix rules are not mentioned in this algorithm because suffix rules are converted to equivalent pattern rules after the makefiles have been read in. For an archive member target of the form `ARCHIVE(MEMBER)', the following algorithm is run twice, first using `(MEMBER)' as the target T, and second using the entire target if the first run found no rule. 1. Split T into a directory part, called D, and the rest, called N. For example, if T is `src/foo.o', then D is `src/' and N is `foo.o'. 2. Make a list of the pattern rules whose target matches T or N. If the target pattern contains a slash, it is matched against T; otherwise, against N. 3. If any rule in that list is *not* a match-anything rule, then remove all nonterminal match-anything rules from the list. 4. Remove any rules with no dependencies from the list. 5. For each pattern rule in the list: 1. Find the stem S: the part of T or N that the `%' in the target pattern matches. 2. Compute the dependency names by substituting S for `%'; if the target pattern does not contain a slash, D is appended to the front of each dependency name. 3. Test whether all the dependencies exist or ought to exist. (If a file name mentioned in the makefile as a target or as an explicit dependency then we say it ought to exist.) If all dependencies exist or ought to exist, then this rule applies. 6. If no pattern rule has been found so far, try harder. For each pattern rule in the list: 1. If the rule is a terminal match-anything rule, ignore it and go on to the next rule. 2. Compute the dependency names as before. 3. Test whether all the dependencies exist or ought to exist. 4. For each dependency that does not exist, follow this algorithm recursively to see if the dependency can be made by an implicit rule. 5. If all dependencies exist, ought to exist, or can be made by implicit rules, then this rule applies. 7. If no rule has been found so far, this target cannot be made by an implicit rule. Return failure. 8. If no implicit rule applies, the rule for `.DEFAULT', if any, applies. In that case, give T the same commands that `.DEFAULT' has. Otherwise, there are no commands for T. When the commands of a pattern rule are executed for T, the automatic variables `$@', `$*' and `$<' are set as follows: `$@' T`$*' If the target pattern contains a slash, this is S; otherwise, it is DS. `$<' The name of the first dependency that came via the implicit rule. For `.DEFAULT' commands, as for non-implicit commands, `$*' and `$<' are empty. `$@' is T, as always.  File: make, Node: Archives, Next: Features, Prev: Implicit, Up: Top Using `make' to Update Archive Files ************************************ "Archive files" are files containing named subfiles called "members"; they are maintained with the program `ar' and their main use is as subroutine libraries for linking. * Menu: * Members: Archive Members. How to name an archive member as a target or dependency. * Update: Archive Update. An implicit rule can update most archive member targets just right. * Symbols: Archive Symbols. Another implicit rule runs `ranlib' to update the special member `__.SYMDEF'.  File: make, Node: Archive Members, Next: Archive Update, Prev: Archives, Up: Archives Archive Members as Targets ========================== An individual member of an archive file can be used as a target or dependency in `make'. The archive file must already exist, but the member need not exist. You specify the member named MEMBER in archive file ARCHIVE as follows: ARCHIVE(MEMBER) This construct is available only in targets and dependencies, not in commands! Most programs that you might use in commands do not support this syntax and cannot act directly on archive members. Only `ar' and other programs specifically designed to operate on archives can do so. Therefore, valid commands to update an archive member target probably must use `ar'. For example, this rule says to create a member `hack.o' in archive `foolib' by copying the file `hack.o': foolib(hack.o) : hack.o ar r foolib hack.o In fact, nearly all archive member targets are updated in just this way and there is an implicit rule to do it for you.  File: make, Node: Archive Update, Next: Archive Symbols, Prev: Archive Members, Up: Archives Implicit Rule for Archive Member Targets ======================================== Recall that a target that looks like `A(M)' stands for the member named M in the archive file A. When `make' looks for an implicit rule for such a target, as a special feature it considers implicit rules that match `(M)', as well as those that match the actual target `A(M)'. This causes one special rule whose target is `(%)' to match. This rule updates the target `A(M)' by copying the file M into the archive. For example, it will update the archive member target `foo.a(bar.o)' by copying the *file* `bar.o' into the archive `foo.a' as a member named `bar.o'. When this rule is chained with others, the result is very powerful. Thus, `make "foo.a(bar.o)"' in the presence of a file `bar.c' is enough to cause the following commands to be run, even without a makefile: cc -c bar.c -o bar.o ar r foo.a bar.o rm -f bar.o Here the file `bar.o' has been envisioned as an intermediate file.  File: make, Node: Archive Symbols, Prev: Archive Update, Up: Archives Updating Archive Symbol Directories ----------------------------------- An archive file that is used as a library usually contains a special member named `__.SYMDEF' that contains a directory of the external symbol names defined by all the other members. After you update any other members, you need to update `__.SYMDEF' so that it will summarize the other members properly. This is done by running the `ranlib' program: ranlib ARCHIVEFILE Normally you would put this command in the rule for the archive file, and make all the members of the archive file dependents of that rule. For example, libfoo.a: libfoo.a(x.o) libfoo.a(y.o) ... ranlib libfoo.a The effect of this is to update archive members `x.o', `y.o', etc., and then update the symbol directory member `__.SYMDEF' by running `ranlib'. The rules for updating the members are not shown here; most likely you can omit them and use the implicit rule which copies files into the archive, as described in the preceding section.  File: make, Node: Features, Next: Missing, Prev: Archives, Up: Top Features of GNU `make' ********************** GNU `make' contains many features not in any other `make' program. Some of them are taken from other versions of `make', while most are new inventions of the implementors of GNU `make'. The standard for comparison among versions of `make' in this chapter will be the version found in standard 4.2 BSD Unix systems. Many additions come from the versions of `make' found in other Unix systems. This chapter lists the features of GNU `make' beyond the 4.2 BSD version. They are presented as a simple list of small items with terse descriptions. All of these features (as well as those found in 4.2 BSD `make') are documented in this manual, so it would be redundant to repeat that documentation here. The `VPATH' variable and its special meaning come from the `make' in 4.3 BSD Unix. *note Directory Search::. Many features come from the version of `make' in Sun Unix systems. I believe that these in turn are adopted from the `make' in Unix System V. * Included makefiles. *note Include::. * Variables are read in from the environment. All variables are placed into the environment of child processes (running commands). *note Environment::. Note also the `-e' option. * The environment variable `MAKEFLAGS' is scanned for command-line options to `make'. The options `-f', `-p', `-d' and `-c' are not accepted. The `make' variable `MAKEFLAGS' is set to a list of the options `make' was invoked with, except those noted above. *note Options/Recursion::. * The automatic variable `$%' is set to the member name in an archive reference. *note Automatic::. * The automatic variables `$@', `$*', `$<' and `$%' have corresponding forms such as `$(@F)' and `$(@D)' which with only the filename and only the directory. *note Automatic::. * Substitution variable references. *note Reference::. * The command-line options `-b' and `-m' are accepted and ignored. * Targets whose commands contain a reference to the variable `MAKE' have their commands executed even if the `-n', `-q' or `-t' options are specified. *note Recursion::. I'm told that Unix System V `make' does this only in the case of `-n'. * An implicit suffix rule `X.a:' makes `LIB(NAME.o)' from `NAME.X'. In GNU `make', this is actually implemented by using one pattern rule for making library-archive files and rule-chaining. *note Chained Rules::. The Sun Unix (and probably System V) version of `make' fails to support variable references using braces (`{' and `}') rather than parantheses (*Note Reference::.), and to set the `MFLAGS' variable to the list of options (the same list as in `MAKEFLAGS'). The remaining new features are inventions new to GNU `make'. * The arrangement of lines and backslash-newline combinations in commands is retained when the commands are printed, so they appear as they do in the makefile, except for the stripping of initial whitespace. * The `-v' option prints version and copyright information. * Simply-expanded variables. *note Flavors::. * The variable `MAKEOVERRIDES' is defined to contain all the variable definitions given on the command line, and is appended to the `MAKE' variable which contains the name by which `make' was invoked. Thus, sub-makes will always get variable definitions from the command line that cannot come from the environment since environment variable definitions do not override those in makefiles. * The `-c' to change directory. *note Options::. * Verbatim variable definitions made with `define'. *note Defining::. * Phony targets. *note Phony Targets::. * Variable expansion functions. *note Functions::. * The `-o' option makes files seem artificially old. *note Avoid Compilation::. * Conditional lines. *note Conditionals::. * Included makefiles never determine the default target. * There is an include file search path. *note Include::. * *note MAKEFILES Variable::. * *note Pattern Rules::. * The automatic variable `$^' contains a list of all dependencies of the current target. *note Automatic::. * There is a fully complete default set of implicit rules using file with suffixes `.out', `.a', `.o', `.s', `.c', `.f', `.p', `.F', `.e', `.r', `.y', `.ye', `.yr' and `.l'. *note Catalogue of Rules::. * Leading sequences of `./' are stripped from file names, so that `./FILE' and `FILE' are considered to be the same file. * Dependencies of the form `-lNAME' are searched for as library archives. *note Libraries/Search::. * Suffixes for suffix rules (*Note Suffix Rules::.) may contain any characters. In other version of `make', they must begin with `.' and not contain any `/' characters. * The variable `MAKELEVEL' keeps track of the current level of `make' recursion. At the top level (`MAKELEVEL' is zero), the `SHELL' environment variable is not used to execute commands. It is reset to `/bin/sh'. * Intermediate implicit files. *note Chained Rules::. * Selective `vpath' search. *note Directory Search::.  File: make, Node: Missing, Next: Concept Index, Prev: Features, Up: Top Missing Features in GNU `make' ****************************** The `make' programs in various other systems support three features that are not implemented in GNU `make'. * A target of the form `FILE((ENTRY))' stands for a member of archive file FILE. The member is chosen, not by name, but by being an object file which defines the linker symbol ENTRY. This feature was not put into GNU `make' because of the nonmodularity of putting knowledge into `make' of the internal format of archive file symbol directories. *note Archive Symbols::. * Suffixes (used in suffix rules) that end with the character `~' have a special meaning; they refer to the SCCS file that corresponds to the file one would get without the `~'. For example, the suffix rule `.c~.o' would make the file `N.o' file from the SCCS file `s.N.c'. For complete coverage, a whole series of such suffix rules is required. *note Suffix Rules::. In GNU `make', this entire series of cases is handled by two pattern rules for extraction from SCCS, in combination with the general feature of rule chaining. *note Chained Rules::. * In System V `make', the string `$$@' has the strange meaning that, in the dependencies of a rule with multiple targets, it stands for the particular target that is being processed. This is not defined in GNU `make' because `$$' should always stand for an ordinary `$'. It is possible to get this functionality through the use of static pattern rules. The System V `make' rule: $(targets): $$@.o lib.a can be replaced with the GNU `make' static pattern rule: $(targets): %: %.o lib.a  File: make, Node: Concept Index, Next: Name Index, Prev: Missing, Up: Top Index of Concepts ***************** * Menu: * $ (function call): Function Syntax. * $ (variable reference): Reference. * - (in commands): Errors. * -i: Errors. * -k: Testing. * -k: Errors. * -n: Echoing. * -n: Instead of Execution. * -o: Avoid Compilation. * -q: Instead of Execution. * -s: Echoing. * -t: Instead of Execution. * :=: Setting. * =: Setting. * @ (in commands): Echoing. * __.SYMDEF: Archive Symbols. * archive: Archives. * archive member targets: Archive Members. * arguments: Function Syntax. * automatic variables: Automatic. * chains of rules: Chained Rules. * commands: Commands. * comments: Makefile Contents. * conditionals: Conditionals. * deletion of target files: Interrupts. * dependency: Rules. * directory search: Directory Search. * double-colon rule: Double-Colon. * echoing (of commands): Echoing. * empty targets: Empty Targets. * environment: Environment. * environment and recursion: Variables/Recursion. * error (in commands): Errors. * execution: Execution. * file name: Wildcards. * flags: Options. * flags for compilers: Implicit Variables. * flavors (of variables): Flavors. * function: Functions. * goal: Goals. * implicit rule: Implicit. * intermediate file: Chained Rules. * interrupt: Interrupts. * makefile: Makefiles. * match-anything rule: Match-Anything Rules. * modified variable reference: Reference. * options: Options. * options and recursion: Options/Recursion. * pattern rule: Pattern Rules. * phony targets: Phony Targets. * precious targets: Special Targets. * recursion: Recursion. * recursive variable expansion: Variables. * recursive variable expansion: Flavors. * recursive variable reference: Reference. * reference to variables: Reference. * rule: Rules. * search path for dependencies: Directory Search. * sequences of commands: Sequences. * setting variables: Setting. * shell: Execution. * signal: Interrupts. * silent operation: Echoing. * simple variable expansion: Variables. * special targets: Special Targets. * static pattern rules: Static Pattern. * stem: Pattern Match. * substitution variable reference: Reference. * suffix rules: Suffix Rules. * target: Rules. * terminal rule: Match-Anything Rules. * touch: Instead of Execution. * value: Variables. * variable: Variables. * varying dependencies: Static Pattern. * vpath: Directory Search. * wildcard: Wildcards.  File: make, Node: Name Index, Prev: Concept Index, Up: Top Index of Functions, Directives and Variables ******************************************** * Menu: * .DEFAULT: Last Resort. * .IGNORE: Errors. * .PHONY: Phony Targets. * .PRECIOUS: Interrupts. * .SILENT: Echoing. * .SUFFIXES: Suffix Rules. * AS: Implicit Variables. * ASFLAGS: Implicit Variables. * CC: Implicit Variables. * CFLAGS: Implicit Variables. * CO: Implicit Variables. * EFLAGS: Implicit Variables. * FC: Implicit Variables. * FFLAGS: Implicit Variables. * GET: Implicit Variables. * LDFLAGS: Implicit Variables. * LEX: Implicit Variables. * LFLAGS: Implicit Variables. * MAKE: MAKE Variable. * MAKEFILES: MAKEFILES Variable. * MAKEFILES: Variables/Recursion. * MAKEFLAGS: Options/Recursion. * MAKELEVEL: Variables/Recursion. * MFLAGS: Options/Recursion. * PC: Implicit Variables. * PFLAGS: Implicit Variables. * RANLIB: Implicit Variables. * RFLAGS: Implicit Variables. * SHELL: Execution. * VPATH: Directory Search. * YACC: Implicit Variables. * YACCE: Implicit Variables. * YACCR: Implicit Variables. * YFLAGS: Implicit Variables. * addprefix: Filename Functions. * addsuffix: Filename Functions. * basename: Filename Functions. * define: Defining. * dir: Filename Functions. * else: Conditional Syntax. * endef: Defining. * endif: Conditional Syntax. * filter: Text Functions. * filter-out: Text Functions. * findstring: Text Functions. * firstword: Filename Functions. * foreach: Foreach Function. * ifdef: Conditional Syntax. * ifeq: Conditional Syntax. * include: Include. * join: Filename Functions. * notdir: Filename Functions. * objects: Simple. * override: Override Directive. * patsubst: Text Functions. * sort: Text Functions. * strip: Text Functions. * subst: Text Functions. * suffix: Filename Functions. * vpath: Directory Search. * wildcard: Filename Functions. * wildcard: Wildcard Function.